Issues in Modeling Locking Performance

This expository article examines the issues that arise when modeling the effect of locking on the performance of transactions in a database system. Perhaps it will interest some performance analysis to see how issues similar to those they have encountered are addressed by others for a different problem; perhaps it will help some graduate student who is about to embark on a modeling project. The issues discussed include the decoupling of data contention and resource contention, the role of simulation, the reliability of intuition, and the techniques for handling stochastic dependencies. The article concludes with a suggestion that performance models be divided into two classes. The models in one class concentrate on studying the fundamental aspects, while those in the other concentrate on answering engineering questions. Such a differentiation in the role of performance models could remove some confusion over what to expect from these models, and how to use their results. A database is a collection of interrelated data. A database management system is a database together with a suite of programs for organizing, updating and querying the database. Typically, users access a database through application programs that run on top of the database management system [KS]. Examples of such applications are airline reservation and automatic teller systems. Database management systems have three important features [B2]: persistence − if a program modifies some data, the changes remain after the program has terminated; sharing − more than one program can concurrently access the data; and reliability − the data must remain correct despite hardware and software failures. In manipulating data, a program may cause the database to be temporarily incorrect. For instance, in transferring an amount of money from an account A to another account B, the database would be incorrect in the interval after the amount is deducted from A and before it is added to B (since that amount is missing from the total of the two accounts for the duration). The persistence of changes and this possibility of a temporary inconsistency lead to the requirement that either all changes made by the program up to its commitment (i.e. successful termination) is reflected in the database, or none at all. This is the concept of the transaction. Since a database system allows several transactions to be active at the same time, the actions of transactions on shared data are interleaved. To prevent this interleaving from producing inconsistent data, …